A user can adjust the initial display settings for an application that uses graphics processing (for example, rendered simulations or games). For example with games, this process currently involves trial and error, in which the user adjusts the settings and then has to play the game to determine whether those settings result in a desired display quality and display frame rate. If the display quality is not desirable (for example, the frame rate stalls), the user then needs to manually adjust the settings. Based on these adjustments, the user's selected settings generally do not stress the available hardware. Retaining smooth motion in the game (for example, so there is no frame rate stalling) means that a lower image quality sequence is displayed.
Multi-graphics processing unit (GPU) rendering systems require a certain amount of bus bandwidth to work properly, wherein a bus includes various types of communication fabrics including point-to-point protocols. Such systems work with an assumed maximum bus latency to help compensate for bus traffic issues related to available bandwidth and bus conflicts. If the bus usage exceeds the system's expected levels, different types of visible issues will become pronounced. It is noted that multiple GPUs can physically exist in multiple semiconductor packages, a single package with multiple semiconductor dies, or a single package with a single semiconductor die.
Because most graphics-intense software varies in how much rendering is required to display updated frames over time (i.e., variable frame rates and bus usage), the rendering settings normally attempt to minimize such bus-caused errors and visible issues. This results in lower frame rates and/or lower rendering quality.
Some multi-GPU rendering systems also use small buffer sizes to reduce system cost. But a small buffer leaves the system more vulnerable to potential latency issues. These cases are even more dependent on ensuring quality by maintaining a worst-case lower frame rate/rendering quality.
At times when the system is not heavily loaded, resources are left idle which could be used to produce faster (i.e., smoother) frame rates and/or improved graphics quality/reality. Because the system settings are normally preset, the worst-case scenario is normally assumed, to ensure a consistent viewing experience.
The existing solutions do not sufficiently address these problems. In one known solution, the frame rate is restricted to be low enough or some rendering settings are restricted to avoid frame failures. This results in less smooth display updates than other solutions or provides a lower quality display. Such restrictions result in less pleasing rendering results and could impact the immersion level in games or accuracy of simulations.
A second known solution is to use more memory for a larger frame buffer to avoid frame failures. This solution is expensive and power-hungry, and may also require more memory than is available in the system. For systems already installed with limited frame buffers, there is normally no option to increase the amount of memory.
A third known solution is to allow for some frame failures and supply a “recovery” mode, which will cause a visible disruption to the image during the frame error time period (of one or more frames). One method in this solution is to display the last “good” frame, resulting in tearing of part or all of the image. Another method in this solution is to allow the failure (visible in failed frames) and perform a recovery on each frame until the failure no longer happens. Either of these methods results in more disruptions to the image when the settings are not optimized to prevent frame errors.